Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / iesg / iesg.93-03-08 < prev next >

Wrap

Text File | 1993-04-22 | 17.0 KB | 443 lines

IETF STEERING GROUP (IESG) REPORT FROM THE IETF MEETING March 8th, 1993 Reported by: Greg Vaudreuil, IESG Secretary This report contains IESG meeting notes, positions and action items. These minutes were compiled by the IETF Secretariat which is supported by the National Science Foundation under Grant No. NCR 8820945. For more information please contact the IESG Secretary. iesg-secretary@cnri.reston.va.us. ATTENDEES --------- Almquist, Philip / Consultant Crocker, Dave / SGI Crocker, Steve / TIS Coya, Steve / CNRI Gross, Philip / ANS Hinden, Robert / SUN Hobby, Russ / UC-DAVIS Huizer, Erik / SURFnet Knowles, Stev / FTP Software Stockman, Bernard / SUNET/NORDUnet Vaudreuil, Greg / CNRI IAB Liaison Chapin, Lyman / BBN Christian Huitema / INRIA Regrets Borman, David / Cray Research Reynolds, Joyce / ISI Piscitello, Dave/ Bellcore AGENDA ------ 1) Administrivia o Role Call o Bash the Agenda o Approval of the Minutes - February 22, 1993 - March 8th 2) Protocol Actions o Path MTU Discovery <Draft> o IESG Advice from Experience with Path MTU Discovery <Informational RFC> o RFC 1327 tutorial <informational RFC> o IEEE 802.5 Token Ring MIB <Draft> o IEEE 802.4 Token Bus MIB <historic> 3) Management Issues o Query sent to SNMP Working Group members o SNMP Security/v2 o Router Requirements o The US Domain, Farnet, and NWnet o MIBs in Waiting 4) Working Group Actions o Authorization and Access Control (aac) 5) Tasked Items o Summarize the New IP Discussions o New IPLPDN charter & milestones o Secure FTP MINUTES ------- 1) Administriva o Approval of the Minutes Discussion and approval of the minutes of both the March 1st and the February 22nd teleconferences was deferred. o Next Meeting The next IESG teleconference was scheduled for Thursday, March 18th, from 11:30 to 1:30 ET. 2) Protocol Actions o MTU Discovery The IESG reviewed the MTU Discovery Protocol as documented in RFC1191. This protocol is widely implemented and is in use in the operational Internet. A known operational problem is documented in a companion document "IESG Advice from Experience with Path MTU Discovery". The IESG approved this protocol for elevation to Draft Standard and the companion document was recommended for publication as an Informational RFC. ACTION: Vaudreuil -- Announce the IESG approval of the MTU Discovery Protocol as a Draft Standard. o RFC 1327 Tutorial This document is a tutorial on the X.400 <=> RFC 822 mail gateway. Consideration was deferred until the next IESG meeting to review the document. o Token Ring MIB The IESG discussed the urgency of considering the Token Ring MIB in the absence of a Network Management Area Director. This protocol has been a proposed standard for over two years and requires review, but there is not strong pressure to elevate it immediately. The IESG agreed to put a review of this protocol on hold pending appointment of a new Area Director. o Token Bus MIB The IESG agreed that the Token Bus MIB could be moved to Historic without having an Network Management Area Director. ACTION: Vaudreuil -- Send out a ballot to the IESG to move the Token Bus MIB to Historic. 3) Management o SNMP Working Group Query Erik Huizer sent out a query to the SNMP Version 2 and SNMP Security Working Groups soliciting comments on the process by which these proposals were submitted and reviewed. Specific comments were made about the steering group management, the split of security into a separate working group, and the compressed timeline, but the comments were generally positive and indicated that the current process should continue. A full summary of this query is included as an Appendix. Until the SNMP working groups submit the protocols to the IESG, there is no further action for the IESG. o Working Group Management Well defined procedures for working groups to follow will help answer specific questions about the standardization process. Erik Huizer has posted an initial document with these procedures and will incorporate lessons learned from the SNMP Evolution process. ACTION: Huizer - Revise the draft of the Working Group guidelines document in light of the SNMP Evolution process and incorporating revisions suggested by Gross and DCrocker. o US Domain Issues about the management of the .us domain were taken off the agenda and will be discussed within the Operations Area. It is not clear there are issues needing IESG attention. o Router Requirements The editor of the Router Requirements documents was contacted and gave a brief status update. The documents are under significant revision, including the splitting of the main document into four and incorporating changes necessary due to the passing of time. There are a few technical details still to work out and it is not expected that this work will be concluded in the next few weeks. The IESG explored options of posting the current documents again as Internet Drafts but reached no firm conclusions about whether the documents which are almost ready should be posted immediately or whether the documents should all be posted as a set. Discussion will continue at the next meeting. o Many Mibs There are several MIBs which have been submitted to the IESG for consideration as Proposed Standard but for which the Area Director review has not been completed. The IESG agreed that advancing these MIBS can be put on hold until a new Network Management Area Director is appointed. 4) Working Group Actions o Authentication and Access Control (aac) The charter was not received by the IESG and needs to be resent before it can be considered. ACTION: Vaudreuil -- Resent the aac charter to the IESG and IAB for consideration as a Working Group. 5) Tasked Items o New IP Status Check The list of New IP contenders has risen to five with the inclusion of Robert Ullmann's IPv7 proposal. The feedback from the IETF suggests that the list of contenders should not be artificially pruned, but that the proposals be evaluated based on some metric of progress. The immediate question facing the IESG is the allocation of presentation time at the March IETF meeting. Rather than give time for open discussion, the IESG agreed that the presentations should present specific information on the progress made since the last meeting. This progress would include information such as new specifications written, implementations tested, and Internet integration and deployment examined. Dave Crocker notified the IESG that the SIP and IPAE Working Groups should now be considered a single effort. ACTION: Knowles -- Query each of the New IP contenders for their current status in anticipation of making presentation time allotments. o IPLPDN There is a lively discussion of the IPLPDN Working Group charter. The negotiations between the Working Group and the IESG continue over limiting the scope of the Charter. o Secure FTP. Preliminary inquiries indicate that Common Authentication Technology may be the proper technology for securing FTP. It appears that the application of CAT to FTP can be done by the CAT Working Group. ACTION: Hobby -- Direct the Secure FTP folks to the CAT Working Group to explore the incorporation of CAT to FTP. Appendix - Summary of Action Items Assigned ACTION: Vaudreuil -- Announce the IESG approval of the MTU Discovery Protocol as a Draft Standard. ACTION: Vaudreuil -- Send out a ballot to the IESG to move the Token Bus MIB to Historic. ACTION: Huizer - Revise the draft of the Working Group guidelines document in light of the SNMP Evolution process and incorporating revisions suggested by Gross and DCrocker. ACTION: Vaudreuil -- Resent the aac charter to the IESG and IAB for consideration as a Working Group. ACTION: Knowles -- Query each of the New IP contenders for their current status in anticipation of making presentation time allotments. ACTION: Hobby -- Direct the Secure FTP folks to the CAT Working Group to explore the incorporation of CAT to FTP. Appendix - Results of the SNMP Community Survey IESG report on SNMPv2 Process Inquiry Erik Huizer 10-March-1993 Introduction ------------ In the Network Management and Security Area of the IETF, two working groups have been working hard to define a new and secure version of SNMP, called SNMPv2. These Working groups are the SNMPv2 Working Group and the SNMP Security Working Group. These WGs have by early 1993 produced 12 Internet Drafts, which they will soon submit to the IESG for advancement to proposed standard status. Recently, from a variety of channels and to more than one member, complaints have reached the IESG which call into question the process by which SNMPv2 has advanced. SNMP is too important and the persistence of background discomfort too significant for the IESG to ignore. Therefore the IESG found it necessary to establish if the complaints are unfounded or not, with the intention of putting matters of the WG's process to rest. To achieve this the IESG through one of its uninvolved members (the author) held an E-mail inquiry amongst the members of the Working Groups, asking for their comments on the process followed in the creation of the SNMPv2 documents. It must be stated that there have been no official complaints made to the IESG, and as such this inquiry is unprecedented, therefore the inquiry included a request for comments on the inquiry itself. This report summarises the results from the inquiry. The Inquiry ----------- The following text was send by E-mail to the distribution lists of the two Working Groups on the 2nd March 1993: "The SNMPv2 process is drawing near to a conclusion with the submission of 12 documents to the IESG. The IESG is working to process these documents as soon as possible. Recently, from a variety of channels and to more than one member, complaints have reached the IESG which call into question the process by which SNMPv2 has advanced. The entire IETF is accountable for the standards it produces, and the IESG is obliged to investigate these complaints to determine whether the process has remained fair and open throughout. The IESG realizes the importance of a broad acceptance of SNMPv2 and finds it necessary to establish that the complaints are unfounded. The IESG has charged me, a non-partisan in the NM area, to approach the community most directly involved with SNMPv2 for input. Therefore I send you this message, and ask each and everyone of you who has comments on the process that led to the creation of SNMPv2 to send me a PERSONAL note. It should present your candid and confidential assessment of the chronology of events leading to the request to advance SNMPv2 to proposed standard, from the original call for contributions through the most recent postings to the mailing list. Since it is equally important to the IESG to hear from those who view the process as having succeeded as not, I urge you to respond. Please rest assured that your correspondence will remain entirely confidential; I will report back to the IESG in a summary fashion. The IESG does not wish this "process checkpoint" to further delay the advancement of these standards. You thus have until monday 8 march 9 am EST to react. This will give me enough time to summarise before the IESG meeting later that day. So if you want to send me a personal note on this subject, do it now, and make sure that it has the same subject line as above, preceded by "re:". I apologise to everyone who feels offended by this note, or by the query. The IESG recognizes that requests of this nature are highly unusual, and deeply regrets having to proceed in this fashion. Indeed, if you find this action to be contrary to the best interests of the community, the IESG is interested in this feedback as well. We are trying to do what is best from the community, and taking the question to the community seems to be our best alternative in this matter." The inquiry was aimed at the process followed, and not at he technical contents of the WGs ofr the documents produced. For comments on the technical contents of documents the IESG will use the normal "Last Call" mechanism. Therefore remarks regarding technical contents of the documents in response to the inquiry have been ignored. The response ------------ The WG on SNMP Security distribution list contained 258 entries at the moment the inquiry was sent. The SNMPv2 distribution list contained 459 entries. Only 37 people responded to the inquiry before the deadline, 27 of them have E-mail addresses that indicate a commercial background. By far the majority of the people who responded (84%) claimed to be passive listeners. I.e. they were interested participants, but did not contribute any new ideas, nor participated actively in discussions on the WG lists. Although it is impossible to draw a unanimous conclusion from the 37 responses, the following observations are supported by at least 75% of the responding people: 1- On the whole the process leading to the 12 Internet Drafts has been as fair as possible and not much different from other IETF WG processes; The current set of documents is cetainly the best that could have been produced in such a short time, and is believed to be the only one to get the majority consensus from the WGs. 2- There has been too much haste in getting the SNMPv2 proposal out; There was no need for the IESG and the Working Groups to set such a sharp deadline (december 1992). This deadline, and the pressure it created made various contributors feel that their proposals did not get the proper attention. Especially a final WG meeting in March (Columbus) would have been a good thing. 3- The WG chairs have acted correctly, and they have done a wonderfull job of making sure that the documents were ready on time; All this within the limited timeframe, and with little leeway to have lengthy discussions on alternative proposals. 4- The authors of the original SMP documents should have been more restrained in their reactions; It was suggested that the original authors should not have been the editors of the final documents, although this clearly would have delayed the WGs. The amount of work put in by the authors is very much appreciated and they are generally acknowledged as THE authorities with respect to SNMP. However, the original SMP authors had too much of a headstart in thinking along the proposed SNMPv2 lines. This made them react (too) fast to alternative proposals, which thus gave the (false) impression of not being considered seriously. The authors also repeatedly used the argument that their proposal was supported by working implementations, while the alternatives were not. This is not a proper argument to be used in a working group when working on a new protocol. 5- The decision to split the work over two Working Groups was unfortunate. The two IESG Area Directors appointed to the process were either too involved, or not involved enough. This lead to miscommunication between the WGs and the IESG. 6- There was no objection against, but also no real necessity for the IESG to do this inquiry. 7- Due to time pressure the security aspects that have been introduced did not get the necessary attention/discussion 8- The concept of a design team going off and preparing an initial working document is applauded. However there should be regular feedback from a design team into the WGs. The current situation where the result of the design team was heralded into the world through the press has been found very counter-productive. The Conclusions and recommendations ----------------------------------- The SNMPv2 documents have been produced according to the normal IETF process with the two involved WGs operating much in the same way as other Working Groups. If there are any remarks to be made about the process they can be traced back to two main errors: - The IESG has failed to manage the SNMPv2 process properly; The main error being that the deadlines put onto the WGs were unnecessary tight. - The authors of the original SMP proposal have chosen an unfortunate way of presenting their proposals 'out of the blue' and defending them. Despite these shortcomings the WG chairs, the authors and other WG members succeeded in getting the documents ready within the agreed deadlines. The "Last Call" mechanism will have to show whether there are still technical issues unresolved that prohibit moving the documents to Proposed Standard and reviewing the results of this before moving them to Draft Standard. The inquiry performed by the IESG was usefull although not perceived to be necessary, and the amount of responses seems to confirm the latter. The IESG should therefore in future refrain from these kind of inquiries unless there are official complaints.